Generating a stub file corresponding to a classified data file

ABSTRACT

Protecting data files is disclosed, including: in response to an indication that a data file has been generated by a client device, determining a security classification associated with the data file; determining that the security classification associated with the data file comprises a classified file; storing the data file in a designated virtual storage area; and generating a stub file at an original storage location of the data file, wherein the stub file includes a viewing permission associated with the data file and a storage location of the data file in the designated virtual storage area.

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 15/158,423, entitled GENERATING A STUB FILE CORRESPONDING TO ACLASSIFIED DATA FILE filed May 18, 2016, which claims priority toPeople's Republic of China Patent Application No. 201510295401.9entitled A METHOD, A DEVICE, AND TERMINAL EQUIPMENT FOR PROTECTING DATAFILES filed Jun. 2, 2015, both of which are incorporated herein byreference for all purposes.

FIELD OF THE INVENTION

The present application relates to the field of Internet technology. Inparticular, the present applications relates to techniques forprotecting data files.

BACKGROUND OF THE INVENTION

In the free and open environment of the Internet, data use, storage, andtransmission all run the risk of leaks. Conventionally, data isprotected by transparent file encryption and decryption methods. Inparticular, an example of a conventional technique of data protectionincludes the following: While a client device operating system isperforming base-level processing, a data file undergoes encryptionprocessing. When a user retrieves a data file, the operating systemdecrypts the data file and then places it in memory for the use of theuser. When the user needs to save the data file, the operating systemencrypts the data file and writes it into a magnetic disk, therebymaking the user completely unaware of the encryption and decryptionactions performed on the data file. Therefore, conventionally, dataleaks are prevented by writing encrypted data into a magnetic disk andperforming the encryption of data in memory. However, these conventionaltechniques do not ensure that the file in memory will not leak.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the invention are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 is a diagram showing an embodiment of a system for protectingdata files.

FIG. 2 is a flow diagram showing an embodiment of a process forprotecting data files.

FIG. 3 is a flow diagram showing an embodiment of a process for sharinga protected data file.

FIG. 4 is a flow diagram showing an embodiment of a process for using aprotected data file.

FIG. 5 is a flow diagram showing an example of a process for accessing aprotected data file.

FIG. 6 is a diagram showing an example client device for protecting datafiles.

FIG. 7 is a diagram showing an example client device for protecting datafiles.

FIG. 8 is a diagram showing an example client device for protecting datafiles.

FIG. 9 is a diagram showing an example data file retrieval device.

FIG. 10 is a diagram showing an example data file retrieval device.

FIG. 11 is a functional diagram illustrating an embodiment of aprogrammed computer system for protecting data files.

DETAILED DESCRIPTION

The invention can be implemented in numerous ways, including as aprocess; an apparatus; a system; a composition of matter; a computerprogram product embodied on a computer readable storage medium; and/or aprocessor, such as a processor configured to execute instructions storedon and/or provided by a memory coupled to the processor. In thisspecification, these implementations, or any other form that theinvention may take, may be referred to as techniques. In general, theorder of the steps of disclosed processes may be altered within thescope of the invention. Unless stated otherwise, a component such as aprocessor or a memory described as being configured to perform a taskmay be implemented as a general component that is temporarily configuredto perform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the invention isprovided below along with accompanying figures that illustrate theprinciples of the invention. The invention is described in connectionwith such embodiments, but the invention is not limited to anyembodiment. The scope of the invention is limited only by the claims andthe invention encompasses numerous alternatives, modifications andequivalents. Numerous specific details are set forth in the followingdescription in order to provide a thorough understanding of theinvention. These details are provided for the purpose of example and theinvention may be practiced according to the claims without some or allof these specific details. For the purpose of clarity, technicalmaterial that is known in the technical fields related to the inventionhas not been described in detail so that the invention is notunnecessarily obscured.

The exemplary embodiments will be explained in detail here. Examplesthereof are presented in the drawings. In cases where the followingdescriptions relate to figures, the same numbers in different figuresrepresent the same or similar elements, unless otherwise indicated. Theimplementations described in the exemplary embodiments below do notrepresent all of the implementations consistent with the presentapplication. On the contrary, they are merely examples of devices andmethods consistent with some aspects of the present application, asdescribed in detail in the claims.

The terms used in the present application merely serve to describespecific embodiments, and are not intended to restrict the presentapplication. The singular forms of “a,” “said,” and “the” used in thepresent application and the attached claims are also intended to includeplural forms, unless otherwise clearly indicated by the context. Also,please understand that the term “and/or” used in this document refers toand contains any or all possible combinations of one or more associatedelements.

Please understand that although the present application employs theterms “first,” “second,” “third,” and so on to describe variousinformation, this information shall not be limited by these terms. Theseterms merely serve to differentiate pieces of information of the samecategory. For example, so long as they remain within the scope of thepresent application, a first piece of information could be called asecond piece of information. Similarly, a second piece of informationcould be called a first piece of information. It depends on the context,for example, the term “if” that is used herein may be interpreted as“when” or “upon being confirmed.”

Embodiments of protecting data files are described herein. In responseto an indication of a generation of a data file at a client device, asecurity classification associated with the data file is determined. Itis determined that the security classification associated with the datafile is a classified file. The data file is then stored in a designatedvirtual storage area. For example, the designated virtual storage areais a part of a cloud server. In various embodiments, a “cloud server”refers to one or more servers that work in concert to provide one ormore services. A stub file is generated at an original storage locationof the data file. Furthermore, the copy of the data file isremoved/deleted from the client device. The stub file includes a viewingpermission associated with the data file and a storage location of thedata file in the designated virtual storage area but not the actualcontent of the data file. Because the stub file does not include anydata from the data file itself, any operations performed by the user onthe stub file at the client device will not have any effect on the datafile, which is stored at a cloud server.

FIG. 1 is a diagram showing an embodiment of a system for protectingdata files. In the example, system 100 includes client device 102,network 104, and cloud server 106. In some embodiments, network 104comprises high speed networks and/or telecommunication networks.

Client device 102 generates a data file. Examples of client device 102include a mobile device, a smart phone, a laptop computer, a desktopcomputer, a tablet device, or any computing device. In some embodiments,client device 102 generates the data file by receiving the data filefrom another client device. In some embodiments, client device 102generates the data file by downloading the data file as an attachmentfrom a message received at client device 102 and/or downloading the datafile from a website. The data file can be generated at client device 102in any appropriate manner. Client device 102 determines a securityclassification associated with the received data file. The securityclassification indicates that the data file is a classified file. Inresponse to determining that the data file is a classified file, clientdevice 102 is configured to store the data file at a designated virtualstorage area. In various embodiments, the designated storage area isdisk (or solid state) storage at cloud server 106. After client device102 sends the data file to cloud server 106 over network 104, clientdevice 102 generates a stub file associated with the data file, removesits copy of the data file, and stores the stub file in the originalstorage location of the data file at client device 102. As such, onceclient device 102 uploads the data file to cloud server 106, clientdevice 102 no longer retains a copy of the data file but rather just thestub file that is associated with the data file. Once cloud server 106has successfully stored the data file, cloud server 106 is configured tosend the storage location of the data file at the designated virtualstorage area to client device 102 over network 104. In variousembodiments, the stub file records various information associated withthe data file including a viewing permission associated with the datafile and a storage location of the data file at the designated virtualstorage area of cloud server 106. The viewing permission associated withthe data file specifies which individual users and/or user roles mayaccess (e.g., read, write, read and write) the data file.

To access the data file, the user of client device 102 is configured toselect the stub file using a virtualized control and managementapplication executing at client device 102. For example, the user ofclient device 102 can browse through stub files of data files that arestored at cloud server 106 via the virtualized control and managementapplication at client device 102. The user of client device 102 canselect the stub file corresponding to a data file to access. In responseto the user's selection to share the stub file, the virtualized controland management application is configured to determine whether the userof client device 102 has permission to access the data file by comparingthe user's identifying information to the viewing permission that isrecorded in the selected stub file. For example, if the user'sidentifying information is specified by the selected stub file to atleast be permitted to read the stub file, then the virtualized controland management application is configured to permit the access action. Inthe event that the user is determined to be able to access the datafile, a virtual application is configured to launch/execute at clientdevice 102 and establish a connection with cloud server 106. The user ofclient device 102 can use a virtual application executing at clientdevice 102 to access the data file stored at cloud server 106, includingby performing word processing operations on the data file. The virtualapplication is isolated from the operating system of client device 102,which means that the operations performed within the virtual applicationare isolated from the storage of client device 102 and/or the memory ofclient device 102.

In some embodiments, a user of client device 102 can share the data filewith another client device (not shown in the diagram) using thevirtualized control and management application executing at clientdevice 102. The user of client device 102 can select the stub filecorresponding to a data file to share with a user associated withanother client device. In response to the user's selection to share thestub file, the virtualized control and management application isconfigured to determine whether the other user with which the data fileis to be shared has permission to access the data file by comparing theother user's identifying information to the viewing permission that isrecorded in the selected stub file. For example, if the user'sidentifying information is specified by the selected stub file to atleast be permitted to read the stub file, then the virtualized controland management application is configured to permit the sharing action.In the event that the other user is determined to be able to access thedata file, the virtualized control and management application isconfigured to send an instruction to the client device of the user withwhich the data file is to be shared. The sent instruction is configuredto generate a copy of the selected stub file at the client device of theuser with which the data file is to be shared such that the other usercan access the data file at cloud server 106 using the stub file.

As such, storing a classified data file in a designated virtual storagearea of cloud server 106 while providing access from client device 102can thus isolate the operations performed on the data file in a virtualenvironment. The use of the virtual environment can therefore preventany malicious accesses to the data file at client device 102 by a userand/or program without the appropriate access permissions or throughtampering with client device 102. Because the stub file records theviewing permission for the data file and the data file's storagelocation in the designated virtual storage area but does not include anydata from the data file itself, any operations performed by the user onthe stub file that is stored at client device 102 will not have anyeffect on the data file stored at cloud server 106.

FIG. 2 is a flow diagram showing an embodiment of a process forprotecting data files. In some embodiments, process 200 is implementedat system 100 of FIG. 1.

At 202, in response to an indication that a data file has been generatedby a client device, a security classification associated with the datafile is determined.

For example, the data file can be generated at the client device throughcopying a new file, downloading a new file, or creating a new file.

In various embodiments, the security classification of the data file isset by a user, such as the user that generated the file, for example. Insome embodiments, the security classification of the data file comprisesa confidentiality grade for the data file. For example, the securityclassification may be set at level 0, level 1, or level 2, where eachlevel represents a different confidentiality grade with respect to thedata file. For example, level 0 indicates that the user does not need toemploy security measures for the data file and level 1 indicates thatthe user needs to take security measures for the data file. In anotherexample, level 0 indicates that the user does not need to employsecurity measures for the data file, level 1 indicates that the userneeds to employ security measures for the data file on the clientdevice, and level 2 indicates that the user needs to employ securitymeasures for the data file on the client device and on the cloud server.

In some embodiments, the content information of a data file can bedetermined first to determine the security classification associatedwith the data file. For example, the content information of the datafile can be matched against a first preset condition and the securityclassification of the data file is determined according to the firstmatch result. For example, the first preset condition may includemultiple key phrases, such as “encrypted,” “private,” or “non-public.”When the system detects that the content information of the data fileincludes content such as “encrypted” or “private,” the securityclassification of the data file according to the first match result canbe determined to be level 1, which indicates that the user needs to takesecurity measures for the data file. If the content information does notcontain the aforementioned key phrases, it is possible to determine thatthe classification level of the data according to the first match resultis level 0, which indicates that the user does not need to take securitymeasures for the data file. In a second example, the file name of a datafile can be matched against a second preset condition and the securityclassification of the data file is determined according to the secondmatch result. For example, the second preset condition may includemultiple key phrases, such as “secret” or “encrypted.” If the systemdetects that the file name of the data file includes content such as“secret” or “encrypted,” the security classification of the data fileaccording to the first match result can be determined to be level 1,which indicates that the user needs to take security measures for thedata file. If the file name does not contain the aforementioned keyphrases, it is possible to determine that the classification level ofthe data according to the second match result is level 0, whichindicates that the user does not need to take security measures for thedata file.

At 204, it is determined that the security classification associatedwith the data file comprises a classified file.

The security classification associated with the data file is determinedbased on a technique, such as one described above, and it is determinedthat the data file is a classified file based on the securityclassification.

In the event that the data file is determined to be an unclassified file(e.g., a file for which there is not required security measures), thenthe data file can be stored normally and/or provided to a user normally.Storage and/or use of unclassified files will not be described further.

At 206, the data file is stored in a designated virtual storage area.

The data file that is determined to be a classified file is stored in adesignated virtual storage area. In some embodiments, the virtualstorage area may be a specific magnetic disk array section that is on amagnetic disk of the client device and that is for storing data filesthat require security measures (e.g., classified files). When the userneeds to access a data file stored in a virtual storage area, a virtualapplication that is isolated (and that may include storage isolation,memory isolation, etc.) from the client device operating system isinitiated at the client device and the data file stored in the virtualstorage area of the client device can be accessed through the virtualapplication.

In some embodiments, the virtual storage area may be a specific magneticdisk array section that is on a magnetic disk of a (e.g., remote) cloudserver and that is for storing data files that require security measures(e.g., classified files). When the user's client device cannot store adata file or cannot adopt security measures for a data file, a virtualapplication that is isolated (and that may include storage isolation,memory isolation, etc.) from the client device operating system isinitiated at the client device and the data file stored in the virtualstorage area of the cloud server can be accessed through the virtualapplication. It is thus possible to isolate any operations performed ona data file stored in the virtual storage area on the cloud serverwithin a virtual environment and prevent the data file from leaking.

At 208, a stub file is generated at an original storage location of thedata file, wherein the stub file includes a viewing permissionassociated with the data file and a storage location of the data file inthe designated virtual storage area.

The data file was stored at an original storage location (e.g., at astorage associated with the client device) prior to being stored at astorage location at the designated virtual storage area. In variousembodiments, once the data file is stored at the designated virtualstorage area, the copy of the data file is deleted from the originalstorage location and a stub file is stored at the original storagelocation instead. In various embodiments, the stub file records theviewing permission(s) associated with the data file and the storagelocation of the data file at the designated virtual storage area. Invarious embodiments, the viewing permission(s) associated with the datafile specifies the specific users and/or the roles (e.g., administratorusers, guest users, guests of a certain group of users) of users thatare allowed to access (e.g., read, write to, read and write to) the datafile.

In various embodiments, when a user selects the stub file at the clientdevice, the stub file stored at the original storage location of thedata file will be read by (e.g., the operating system of) the clientdevice to determine whether the selecting user has viewing permission.The data file may be retrieved from the storage location in thedesignated virtual storage area only if it has been determined that theselecting user has viewing permission to access the data file.Thereupon, the data file is viewed from the storage position in thedesignated virtual storage area. As will be described in further detailbelow, accessing the data file from the designated virtual storagesystem includes running a virtualized environment that provides accessto the data file at the designated virtual storage area (e.g., of acloud server). However, if the selecting user does not have viewingpermission, the selecting user is denied access to the data file in thedesignated virtual storage area.

FIG. 3 is a flow diagram showing an embodiment of a process for sharinga protected data file. In some embodiments, process 300 is implementedat system 100 of FIG. 1.

At 302, a first instruction is received from a first user to share adata file with a second user.

In some embodiments, a first user can share a data file with anotheruser by using a client device application or a stub file-sharing key toinitiate sharing the stub file with a designated other user. In someembodiments, the data file to be shared is already uploaded to a cloudserver and only the stub file that corresponds to the data file isstored at the client device of the user that wishes to share the datafile with the other user.

At 304, user information associated with the second user is determined.In some embodiments, user information may include the account number ofthe other user in the client application, or it may include an emailaddress where the other user can receive the data file. In other words,the present application does not impose restrictions concerning theaddress contained in the user information with which data files can beshared. All that is necessary is that the other user is enabled toreceive the data file.

At 306, it is determined whether the second user has permission toaccess the data file based at least in part on the user informationassociated with the second user. In the event that the second user isdetermined to have permission to access the data file, control istransferred to 308. Otherwise, in the event that the second user isdetermined not to have permission to access the data file, the seconduser is denied access to the data file (e.g., a message that the datafile cannot be shared with him/her is sent to the second user) andprocess 300 ends.

The user information associated with the second user is compared to theviewing permission associated with the data file that is included in thestub file of the data file to determine whether the second user haspermission to access the data file. For example, the user informationassociated with the second user can include identifying informationassociated with the second user and/or a role associated with the seconduser.

At 308, the data file is uploaded to and stored at a designated virtualstorage area of a cloud server.

In some embodiments, if a copy of the data file is not already uploadedto and stored at the designated virtual storage area of a cloud server(e.g., for backup storage), then a copy of the data file is uploaded tothe designated virtual storage area of a cloud server. For example, thefirst user that wishes to share the data file with the second user mayuse a client device application or a stub file upload key to upload thedata file to a cloud server. In some embodiments, the client applicationmay be virtualized control and management software installed on theclient device.

At 310, a second instruction is sent to a client device associated withthe second user, wherein the second instruction is configured togenerate a stub file corresponding to the data file at the client deviceassociated with the second user.

In some embodiments, identifying information associated with the seconduser is determined from the user information associated with the seconduser. After the second user receives the second instruction through thecorresponding client device, a stub file for the data file on the clientdevice of the second user is generated based on the second instruction.For example, the generated copy of the stub file is stored at anoriginal location that the data file would have been stored at theclient device of the second user. The second user's client device canthen use the stub file as a basis for acquiring the data file from thedesignated virtual storage area of the cloud server. As described above,in various embodiments, the stub file records the viewing permission(s)associated with the data file and the storage location of the data fileat the designated virtual storage area.

As described in process 300, when there is a need to share a data file,a second instruction is sent to the second user according to the userinformation. After the second user confirms receipt of the data filethrough their client device, a data file stub file is generated on thesecond user's client device. Therefore, the sharing of a data file thatneeds to be kept confidential is virtually shared by sharing a stubfile. Because the underlying data of the data file is not sent to thesecond user and the shared stub file only stores the storage locationand viewing permission of the data file in a virtual storage area anddoes not include any data information of the data file itself, anyoperations performed by the second user on his or her copy of the stubfile will not have any effect on the data file. This ensures that noconfidential information will be leaked from the data file in thesharing process.

FIG. 4 is a flow diagram showing an embodiment of a process for using aprotected data file. In some embodiments, process 400 is implemented atsystem 100 of FIG. 1.

At 402, a user selection associated with a stub file is received at aclient device.

A user selection associated with a stub file is received at a clientdevice. In various embodiments, the stub file corresponds to a data filethat is stored in a designated virtual storage area of a cloud serverand is generated based on a process such as process 200 of FIG. 2 orprocess 300 of FIG. 3. For example, the stub file was displayed in afile browser application that is executing at the client device. In someembodiments, the stub file is displayed in the file browser applicationin the same manner as the data file with which it is associated wouldhave been displayed had it been stored locally at the client device,instead of at a designated virtual storage area of a cloud server.

In some embodiments, a client application installed on the client devicemay be used to monitor for stub file-related click events. In someembodiments, a user has already logged onto the client application usingthe user's credentials. In some embodiments, the click event can be adouble-click event on the stub file or it may be a click event on thestub file when it is displayed on a presented menu or file browserapplication. In some embodiments, the client application may record thestub files and thus be able to determine whether a clicked file is astub file or an ordinary data file.

At 404, it is determined whether a user associated with the userselection has permission to access a data file associated with the stubfile based at least in part on a viewing permission associated with thedata file that is included in the stub file. In the event that the userassociated with the user selection does have permission to access thedata file, control is transferred to 406. Otherwise, in the event thatthe user associated with the user selection does not have permission toaccess the data file, the user is denied access to the data file andprocess 400 ends.

As described above, a stub file records the viewing permission of acorresponding data file and the storage location of the data file in thedesignated virtual storage area of the cloud server. User informationassociated with the user that had made the selection of the stub file iscompared to the viewing permissions included in the stub file todetermine whether the user associated with the selection is a user thathas viewing permission of the data file.

At 406, a virtual application corresponding to the data file isinitiated at the client device.

At 408, access to the data file at a designated virtual storage area isprovided using the virtual application.

In various embodiments, the virtual application is a virtualized controland management software application installed on the client device. Invarious embodiments, the virtual application is isolated from theoperating system of the client device. In various embodiments, theisolation of the virtual application from the operating system mayinclude storage isolation from the operating system and it may alsoinclude memory isolation from the operating system. Thus, the virtualapplication can ensure that any operation performed by the user on thedata file is isolated within the virtual environment as provided by thevirtual application and thereby prevents malicious users that are notgranted access to the virtual application from obtaining any dataresources from within the virtual application. In some embodiments, theuser's access to the data file via the virtual application may includenormal reading, editing, and use of clipboards, for example. In someembodiments, operations performed by the user on the data file will beexecuted at the cloud server at which the data file is stored and not onthe client device at which the stub file is stored. In variousembodiments, the virtual application is configured to locate the datafile stored at the designed virtual storage area of a cloud server usingthe storage location of the data file that is included in the stub file.FIG. 5 below shows an example of using the virtual application to accessa data file stored at the designed virtual storage area of a cloudserver.

FIG. 5 is a flow diagram showing an example of a process for accessing aprotected data file. In some embodiments, process 500 is implemented atsystem 100 of FIG. 1.

In various embodiments, a stub file corresponding to a (e.g.,classified) data file is stored on a client device while the data fileis stored in a designated virtual storage area on a cloud server.Process 500 is an example of a process for obtaining the data file fromthe designated virtual storage area on the cloud server using a virtualapplication after the stub file was selected at the client device (e.g.,as described in process 400 of FIG. 4, above).

At 502, a client device initiates a remote desktop protocol (RDP)component to connect to a cloud server at which a data file is storedbased at least in part on information included in a stub file associatedwith the data file.

After detecting that a user has selected the stub file at the clientdevice (e.g., using a process such as process 400 of FIG. 4, above), theclient device starts a remote desktop protocol (RDP) component accordingto the information recorded in the stub file. The RDP component is anexample virtual application that can be used to access a data file at acloud server at which the data file is accessed. The RDP component isused to connect to the cloud server at which the data file is stored.

At 504, the client device transmits the information included in the stubfile via the RDP component to the cloud server.

In some embodiments, all the data information recorded in the stub filehas been encrypted by a client application. The encrypted dataapplication records the information associated with the data filecorresponding to the stub file including, for example, one or more of:the storage location of the data file at the designated virtual storagearea of the cloud server, user permissions for the data file, the datafile-sharing procedure, and historical records on use of the data file.In some embodiments, information included in the stub file that istransmitted from the client device to the cloud server includes, forexample, one or more of: a storage location of a designated virtualstorage area of the cloud server at which the data file is stored,client application user permissions, information that the user needs tovalidate, and the virtual storage path on the server for the data filethat is to be opened.

At 506, after the cloud server verifies the transmitted information, thecloud server starts a remote virtualization program on the client deviceand opens the data file on the cloud server according to a designatedvirtual storage area storage location included in the stub file.

At 508, the cloud server maps a document editor program onto the clientdevice.

In some embodiments, the cloud server may establish a new editable fileusing a document editor program (e.g., Microsoft Word) and then transmitthe entire visible window for the editable file onto the client device.A remote document editor can thus be mapped onto the client device. Insome embodiments, mapping the document editor onto the client deviceincludes sending a user interface of the document editor to be presentedat the client device.

At 510, the client device uses the document editor program to performoperations on the data file stored on the cloud server.

In some embodiments, the operations that are received at the clientdevice from a user to perform on the data file using the document editorprogram that is mapped by the cloud server onto the client device mayinclude viewing or editing the data file contents and copying the datafile, for example. The user operations performed through the documenteditor program user interface at the client device are sent to the cloudserver and then executed on the data file at the cloud server. Thepresent application imposes no restrictions as to the specificoperations vis-à-vis the data file.

In a first example, after a first user shares a (e.g., classified datafile) with a second user (e.g., using a process such as process 300 ofFIG. 3), the second user receives only a stub file at his or her clientdevice rather than a copy of the data file itself. When the second userneeds to use the stub file as a basis to obtain the data file from thecloud server, the second user can select the stub file stored at theclient device of the second user and processes such as process 400 ofFIG. 4 and process 500 of FIG. 5 can be used to provide the user accessto the data file that is stored at a designated virtual storage area ofthe cloud server.

In a second example, if the data file is stored in a designated virtualstorage area of the cloud server because the client device magnetic diskhas limited storage space or is not set up with a virtual storage area,processes such as process 400 of FIG. 4 and process 500 of FIG. 5 can beused to provide a user of a client device access to the data file fromthe virtual area of the cloud server when the user needs to obtain thedata file from the cloud server based on the stub file.

In a third example, when a user needs to perform operations on a datafile from a cloud server via a different client device, process 400 ofFIG. 4 and process 500 of FIG. 5 can be used to provide access to thedata file remotely. For example, a user on client device A generates astub file for a data file and stores the data file in a virtual area ofclient device A. When the user sends the stub file from client device Ato client device B, and after client device A uploads the data file tothe cloud server, the user can use process 400 of FIG. 4 and process 500of FIG. 5 to perform operations on the data file from the cloud serverif the user needs to retrieve the data file from client device B.

The virtualization cost of applications such as Citrix XenApp and othersuch applications can be quite high. Thus, as described above, thepresent application can use, for example, a Windows operating system byemploying an RDP-based application virtualization scheme. By using anRDP control component, a message hook, and window clipping technology,remote application virtualization technology can be achieved, thusavoiding reliance on a client device's own operating system and enablingthe cloud server to employ any Windows operating system, which is moreflexible for the user of the data file.

The following example is based on the embodiments described above: Whena data file is subjected to operations by a user, a client applicationinstalled on the client device may also be used to monitor theoperations performed by the user on the data file. In some embodiments,the operations performed by the user on the data file may be performedon the client device or they may be performed on the data file by theuser via a document editor mapped onto the client device from the cloudserver, thus allowing for effective monitoring and management of datafile opening, operating, flowing, and all other data file-relatedactions that are performed by the user.

FIG. 6 is a diagram showing an example client device for protecting datafiles. As shown in the example, the client device comprises a processor,an internal bus, network ports, internal memory, and non-volatilememory. In practice, the client device may also include other hardwareas needed to perform business services. The processor can obtain acorresponding computer program from the non-volatile memory to theinternal memory and then execute it. The data file protection device isformed in the logical layer. The present application does not excludeother implementations in addition to a software implementation, e.g., alogic device or a combined software/hardware form. In other words, theentity that executes the processes as described above need not belimited to various logical units and can be hardware, software, or acombination of both.

FIG. 7 is a diagram showing an example client device for protecting datafiles. In the example, device 700 includes first determining module 71,storage module 72, and a stub generating module 73.

The modules and units can be implemented as software componentsexecuting on one or more processors, as hardware such as programmablelogic devices, and/or Application Specific Integrated Circuits designedelements can be embodied by a form of software products which can bestored in a nonvolatile storage medium (such as optical disk, flashstorage device, mobile hard disk, etc.), including a number ofinstructions for making a computer device (such as personal computers,servers, network equipment, etc.) implement the methods described in theembodiments of the present invention. The modules and units may beimplemented on a single device or distributed across multiple devices.

First determining module 71 is configured to determine the securityclassification of a data file and an original storage location of thedata file in response to a generation of the data file on the clientdevice.

Storage module 72 is configured to store the data file in a designatedvirtual storage area if the security classification determined by thefirst determining module indicates that the data file is a classifiedfile.

Stub generating module 73 is configured to generate a stub file at theoriginal storage location determined by first determining module 71. Thestub file is configured to record the viewing permission for the datafile and the storage location of the data file in the designated virtualstorage area.

FIG. 8 is a diagram showing an example client device for protecting datafiles. In some embodiments, device 800 is an example implementation ofdevice 700 of FIG. 7. In the example of device 800, first determiningmodule 71 of device 700 includes first determining unit 711, firstmatching unit 712, second determining unit 713, and second matching unit714. Device 800 further includes monitoring module 78, storage module72, second determining module 74, sending module 75, third determiningmodule 76, uploading module 77, and stub generating module 73.

First determining unit 711 is configured to determine the contentinformation of the data file.

In some embodiments, first matching unit 712 is configured to match thecontent information determined by first determining unit 711 against afirst preset condition and determine the security classification of thedata file according to the first matching result.

In some embodiments, second determining unit 713 is configured todetermine the file name of the data file.

A second matching unit 714 is configured to match the file namedetermined by second determining unit 713 against a second presetcondition and determine the security classification of the data fileaccording to the second matching result.

Second determining module 74 is configured to determine user informationfor a second user upon detecting a first instruction that indicates thata first user selects to share the data file that was stored by storagemodule 72 with a second user's client device that is designated by thefirst user.

Sending module 75 is configured to use the user information determinedby second determining module 74 as a basis for sending to the seconduser a second instruction for instructing the second user to receive thedata file. After the second user receives the data file through thecorresponding client device, in some embodiments, sending module 75 isconfigured to generate a stub file for the data file on the clientdevice of the second user.

Third determining module 76 is configured to use the user informationdetermined by second determining module 74 as a basis for determiningwhether the second user has viewing permission with respect to the datafile.

Uploading module 77 is configured to receive an indication from thirddetermining module 76 associated with a determination that the seconduser has viewing permission with respect to the data file. In responseto the indication, uploading module 77 is configured to upload the datafile to a cloud server and store it such that the result is that thesecond user is able to use the stub file as a basis for acquiring thedata file from the cloud server.

Monitoring module 78 is configured to use a client application installedon the client device to monitor the user operations that are performedby the user on the data file.

FIG. 9 is a diagram showing an example data file retrieval device. Inthe example, device 900 includes fourth determining module 91, startingmodule 92, and accessing module 93.

Fourth determining module 91 is configured to determine whether a userassociated with selecting a stub file has permission to access the datafile according to the viewing permission recorded by the stub file.

In the event that fourth determining module 91 determines that the userdoes have permission to access the data file, starting module 92 isconfigured to initiate a virtual application corresponding to the datafile.

Accessing module 93 is configured to use the virtual application startedby starting module 92 to access the data file stored at the designatedvirtual storage area storage location recorded by the stub file.

FIG. 10 is a diagram showing an example data file retrieval device. Insome embodiments, device 900 of FIG. 9 can be implemented using theexample of device 1000. In the example of device 1000, accessing module93 includes network connecting unit 931, transmitting unit 932, andoperating unit 933.

Network connecting unit 931 is configured to connect to a cloud serverthrough a remote desktop protocol component on the basis of informationrecorded by a stub file associated with a data file to be accessed.

Transmitting unit 932 is configured to transmit information recorded bythe stub file via the remote desktop protocol component to the cloudserver so that after the cloud server successfully verifies theinformation recorded by the storage file, the cloud server initiates aremote virtualization program on the client device and uses thedesignated virtual storage location recorded by the stub file as a basisfor mapping a document editor program for editing the data file storedon the cloud server to the client device.

Operating unit 933 is configured to perform operations on the data filestored on the cloud server through the document editor.

FIG. 11 is a functional diagram illustrating an embodiment of aprogrammed computer system for protecting data files. As will beapparent, other computer system architectures and configurations can beused to protect data files. Computer system 1100, which includes varioussubsystems as described below, includes at least one microprocessorsubsystem (also referred to as a processor or a central processing unit(CPU)) 1102. For example, processor 1102 can be implemented by asingle-chip processor or by multiple processors. In some embodiments,processor 1102 is a general purpose digital processor that controls theoperation of the computer system 1100. Using instructions retrieved frommemory 1110, the processor 1102 controls the reception and manipulationof input data, and the output and display of data on output devices(e.g., display 1118).

Processor 1102 is coupled bi-directionally with memory 1110, which caninclude a first primary storage area, typically a random access memory(RAM), and a second primary storage area, typically a read-only memory(ROM). As is well known in the art, primary storage can be used as ageneral storage area and as scratch-pad memory, and can also be used tostore input data and processed data. Primary storage can also storeprogramming instructions and data, in the form of data objects and textobjects, in addition to other data and instructions for processesoperating on processor 1102. Also as is well known in the art, primarystorage typically includes basic operating instructions, program code,data, and objects used by the processor 1102 to perform its functions(e.g., programmed instructions). For example, memory 1110 can includeany suitable computer readable storage media, described below, dependingon whether, for example, data access needs to be bi-directional oruni-directional. For example, processor 1102 can also directly and veryrapidly retrieve and store frequently needed data in a cache memory (notshown).

A removable mass storage device 1112 provides additional data storagecapacity for the computer system 1100 and is coupled eitherbi-directionally (read/write) or uni-directionally (read only) toprocessor 1102. For example, storage 1112 can also include computerreadable media such as magnetic tape, flash memory, PC-CARDS, portablemass storage devices, holographic storage devices, and other storagedevices. A fixed mass storage 1120 can also, for example, provideadditional data storage capacity. The most common example of fixed massstorage 1120 is a hard disk drive. Mass storages 1112, 1120 generallystore additional programming instructions, data, and the like thattypically are not in active use by the processor 1102. It will beappreciated that the information retained within mass storages 1112 and1120 can be incorporated, if needed, in standard fashion as part ofmemory 1110 (e.g., RAM) as virtual memory.

In addition to providing processor 1102 access to storage subsystems,bus 1114 can also be used to provide access to other subsystems anddevices. As shown, these can include a display 1118, a network interface1116, a keyboard 1104, and a pointing device 1108, as well as anauxiliary input/output device interface, a sound card, speakers, andother subsystems as needed. For example, the pointing device 1108 can bea mouse, stylus, track ball, or tablet, and is useful for interactingwith a graphical user interface.

The network interface 1116 allows processor 1102 to be coupled toanother computer, computer network, or telecommunications network usinga network connection as shown. For example, through the networkinterface 1116, the processor 1102 can receive information (e.g., dataobjects or program instructions) from another network or outputinformation to another network in the course of performingmethod/process steps. Information, often represented as a sequence ofinstructions to be executed on a processor, can be received from andoutputted to another network. An interface card or similar device andappropriate software implemented by (e.g., executed/performed on)processor 1102 can be used to connect the computer system 1100 to anexternal network and transfer data according to standard protocols. Forexample, various process embodiments disclosed herein can be executed onprocessor 1102, or can be performed across a network such as theInternet, intranet networks, or local area networks, in conjunction witha remote processor that shares a portion of the processing. Additionalmass storage devices (not shown) can also be connected to processor 1102through network interface 1116.

An auxiliary I/O device interface (not shown) can be used in conjunctionwith computer system 1100. The auxiliary I/O device interface caninclude general and customized interfaces that allow the processor 1102to send and, more typically, receive data from other devices such asmicrophones, touch-sensitive displays, transducer card readers, tapereaders, voice or handwriting recognizers, biometrics readers, cameras,portable mass storage devices, and other computers.

As described in various embodiments above, when a data file isdetermined to be a classified file, the data file is stored to adesignated virtual storage area. Therefore, user operations on the datafile stored in the designated virtual storage area can be isolatedwithin a virtual environment and prevent the data file from beingtampered with by malicious users and/or programs at a client device fromwhich the data file is accessed. A stub file is generated at theoriginal storage location of the data file at a client device. Becausethe stub file only records the viewing permission for the data file andthe data file's storage location in the virtual storage area and doesnot include any data from the data file itself, any operations performedby the user on the stub file will not have any effect on the data file.

Upon considering the invention disclosed here in the description and inpractice, persons skilled in the art shall easily think of other schemesfor implementing the present application. The present applicationintends to cover any variation, use, or adaptation of the presentapplication where these variations, uses, or adaptations comply with thegeneral principles of the present application and include publicknowledge or customary technical means in the art that have not beendisclosed by the present application. The description and embodimentsare regarded merely as illustrative. The true scope and spirit of thepresent application are indicated by the claims below.

Please also note that the term “comprise” or “contain” or any of theirvariants are to be taken in their non-exclusive sense. Thus, processes,methods, merchandise, or equipment that comprise a series of elementsnot only comprise those elements, but also comprise other elements thathave not been explicitly listed or elements that are intrinsic to suchprocesses, methods, merchandise, or equipment. In the absence of furtherlimitations, elements that are limited by the phrase “comprises a(n) . .. ” do not exclude the existence of additional identical elements inprocesses, methods, merchandise, or equipment that comprise saidelements.

The above-described are merely preferred embodiments of the presentapplication and do serve to limit the present application. Anymodifications, equivalent substitutions, or improvements that areperformed shall be contained within the protective scope of the presentapplication.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the invention is not limitedto the details provided. There are many alternative ways of implementingthe invention. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. (canceled)
 2. A system, comprising: a processorconfigured to: store a data file in a designated virtual storage area;generate a stub file at an original storage location of the data file,wherein the stub file includes a viewing permission associated with thedata file and a storage location of the data file in the designatedvirtual storage area; receive a user selection associated with the stubfile to access the data file; receive an indication that a userassociated with the user selection has permission to access the datafile; in response to the indication, execute a virtual applicationcorresponding to the data file; and provide access to the data file atthe designated virtual storage area using the virtual application; and amemory coupled to the processor and configured to provide the processorwith instructions.
 3. The system of claim 2, wherein the designatedvirtual storage area is associated with a cloud server.
 4. The system ofclaim 2, wherein the processor is further configured to determine asecurity classification associated with the data file.
 5. The system ofclaim 4, wherein to determine the security classification associatedwith the data file comprises to: compare content information associatedwith the data file against a preset condition; and determine thesecurity classification based at least in part on a result of thecomparison.
 6. The system of claim 4, wherein the securityclassification associated with the data file is set by a user.
 7. Thesystem of claim 2, wherein the processor is further configured to storethe stub file at the original storage location associated with the datafile.
 8. The system of claim 2, wherein to provide access to the datafile at the designated virtual storage area using the virtualapplication includes to: transmit information included in the stub fileto a cloud server associated with the designated virtual storage area;and receive a user interface associated with a document editor programfrom the cloud server.
 9. The system of claim 2, wherein to provideaccess to the data file at the designated virtual storage area using thevirtual application includes to: transmit information included in thestub file to a cloud server associated with the designated virtualstorage area; receive a user interface associated with a document editorprogram from the cloud server; receive an operation to be performed onthe data file via the user interface; and send the operation to thecloud server.
 10. The system of claim 2, wherein the stub file comprisesa first stub file and wherein the processor is further configured to:receive a first instruction from a first user to share the data filewith a second user; determine user information associated with thesecond user; determine that the second user has permission to access thedata file based at least in part on the user information associated withthe second user; and send a second instruction to a client deviceassociated with the second user, wherein the second instruction isconfigured to generate a second stub file corresponding to the data fileat the client device associated with the second user.
 11. A method,comprising: storing a data file in a designated virtual storage area;generating a stub file at an original storage location of the data file,wherein the stub file includes a viewing permission associated with thedata file and a storage location of the data file in the designatedvirtual storage area; receiving a user selection associated with thestub file to access the data file; receiving an indication that a userassociated with the user selection has permission to access the datafile; in response to the indication, executing a virtual applicationcorresponding to the data file; and providing access to the data file atthe designated virtual storage area using the virtual application. 12.The method of claim 11, wherein the designated virtual storage area isassociated with a cloud server.
 13. The method of claim 11, furthercomprising determining a security classification associated with thedata file.
 14. The method of claim 13, wherein determining the securityclassification associated with the data file comprises: comparingcontent information associated with the data file against a presetcondition; and determining the security classification based at least inpart on a result of the comparison.
 15. The method of claim 13, whereinthe security classification associated with the data file is set by auser.
 16. The method of claim 11, further comprising storing the stubfile at the original storage location associated with the data file. 17.The method of claim 11, further comprising providing access to the datafile at the designated virtual storage area using the virtualapplication includes: transmitting information included in the stub fileto a cloud server associated with the designated virtual storage area;and receiving a user interface associated with a document editor programfrom the cloud server.
 18. The method of claim 11, wherein providingaccess to the data file at the designated virtual storage area using thevirtual application includes: transmitting information included in thestub file to a cloud server associated with the designated virtualstorage area; receiving a user interface associated with a documenteditor program from the cloud server; receiving an operation to beperformed on the data file via the user interface; and sending theoperation to the cloud server.
 19. The method of claim 11, wherein thestub file comprises a first stub file and further comprising: receivinga first instruction from a first user to share the data file with asecond user; determining user information associated with the seconduser; determining that the second user has permission to access the datafile based at least in part on the user information associated with thesecond user; and sending a second instruction to a client deviceassociated with the second user, wherein the second instruction isconfigured to generate a second stub file corresponding to the data fileat the client device associated with the second user.
 20. A computerprogram product, the computer program product being embodied in anon-transitory computer readable storage medium and comprising computerinstructions for: storing a data file in a designated virtual storagearea; generating a stub file at an original storage location of the datafile, wherein the stub file includes a viewing permission associatedwith the data file and a storage location of the data file in thedesignated virtual storage area; receiving a user selection associatedwith the stub file to access the data file; receiving an indication thata user associated with the user selection has permission to access thedata file; in response to the indication, executing a virtualapplication corresponding to the data file; and providing access to thedata file at the designated virtual storage area using the virtualapplication.